-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
properly output esm #1331
properly output esm #1331
Conversation
🦋 Changeset detectedLatest commit: dfce529 The changes in this PR will be included in the next version bump. This PR includes changesets to release 17 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
525c3bf
to
49c2911
Compare
49c2911
to
c98029f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so tsc-alias
ensures that module paths are correctly resolved to relative paths? assuming this is related to the export name / path mangling that was happening?
81cf3ca
to
ac85998
Compare
ac85998
to
dfce529
Compare
uses
tsc-alias
to generate correct import paths for esm supportthis may have been related to issues @VanishMax was experiencing
this should permit esm resolution to work properly for the packages' internal modules
edit: okay, tsc-alias doesn't completely solve the issue -
bundlers are fine now, but anything that needs to use node module resolution (vitest, many consumers) will encounter problems because our packages currently use nonstandard module resolution to identify imports from external dependencies.
the tsc-alias tool is only indended for internal paths.
probably we should just comply with esm path spec internally, but that would require changing nearly every import in the codebase, so this PR now combines tsc-alias and changes imports to name external 'js' files that are not resolved via package.json exports.
this mainly just means pb types imports now require a 'js' extension, because those generated packages don't actually define any exports or main configuration.
there's hundreds of pb type imports, so it's a large diff. but this means we don't have to configure a bundler for every package, and the packages should have much better support for many consumers.
edit again:
instead of literally modifying imports, now mutating in a more custom way
this solution is bad. eventually a larger linter/bundler reconfig should happen